Traditionally, telephony applications have been built within isolated, vertical platforms—i.e., self-contained boxes, each performing a fixed set of functions. Vertical applications are generally external to a service provider's (e.g., cellular network operator's) platform.
Typically, each vertical application identifies and hosts a single telephony service function. An example of such a function is a Class 5 feature server, which is typically used to provide basic dialing functionality to the cell phone subscribers of the network. A Class 5 feature server is usually embodied in a single vertical application. Another example of a stand-alone, external application is a voice mail server. Each service provider's platform can be serviced by a plurality of vertical applications, each defining an isolated service for the telephone network. Such applications are usually specifically designed by each particular vendor, hence providing little opportunity for enhancements and addition of functions. Generally, custom modifications to traditional telephony applications required a substantial financial investment, as well as time to implement, test, and deploy. Therefore, technological and market developments could not be easily accommodated.
More recently, however, service providers have recognized that differentiated services drive markets more so than price competition models. Accordingly, they have offered groups of services, sometimes closely bundled, in order to attract new subscribers. Unfortunately, as mentioned above, traditional telephony applications do not typically provide custom functions, and do not lend themselves to integration. Attempts have been made in the past to provide open application environments that facilitate the development of new applications for providing custom services. However, such open application environments frequently require that service providers write their custom applications entirely. This has proven to require more investment than the service provider could justify.
One current attempt to mitigate the shortcomings is a system called a Service Capability Interaction Manager (SCIM), and it is defined through the IP Multimedia Subsystem (IMS) consortium effort. SCIM systems include a layer between the underlying Internet Protocol (IP) service network and the vertical applications, and that layer provides for multiplexing the subscriber session among multiple vertical applications. A problem with this solution is that it is very bottom-up because it arises from a network-centric view of telephony. A typical SCIM system uses only the underlying IP mechanisms to make decisions regarding steering the subscriber among the vertical applications hosted by the service provider's platform. It is usually a very rigid way of predicting what the subscriber is going to do. In other words, SCIM does not provide a way to define a new service operation; rather, it inserts an additional piece of intelligence between a subscriber and the vertical applications to steer the subscriber to services based on its signaling.
Another recent trend is to move away from individual vertical applications and go to a more open and top-down way of defining applications through a Service Oriented Architecture (SOA). Instead of being underneath at the network layer discovering what a subscriber is accessing, an SOA system sequences a subscriber through a pre-described set of operations across multiple vertical applications. SCIM systems typically do not fit within an SOA framework.